Existing second generation cellular radio communication systems such as GSM are in the process of being supplemented and to some extent replaced by third generation systems. These include the 3G system known as Universal Mobile Telecommunications System (UMTS). Security is a key component of the UMTS standards and is intended to be superior to second generation system security, whilst at the sane time ensuring compatibility with GSM to ease both migration from GSM to UMTS and handover between GSM and UMTS access networks. The design of the authentication and key agreement (AKA) protocol for UMTS (see 3G TS 33.102) is intended to satisfy these objectives, at least with respect to authenticating subscribers to an access network and securing user data over the radio link.
The AKA protocol involves three communicating parties, namely the authentication centre (AuC) in the home environment (HE) of the user, the visitor location register (VLR) in the serving network (SN) of the user, and the user itself, represented by his or her UMTS subscriber identity module (USIM). A secret key is shared by the AuC and the USIM. Following receipt of an authentication data request by the HE, the AuC generates an array of (n) authentication vectors. This array is then sent to the SN and is good for n authentication attempts by the user. The SN selects the next vector in the array, and sends certain components of the vector to the USIM. These allow the USIM to verify the SN, compute session keys, and generate a response. The latter is returned to the SN which compares it with an expected response contained in the chosen vector. If they match, the SN assumes the authentication exchange to have been successfully completed. The established session keys are then transferred by the USIM to the user's mobile equipment and by the VLR to the serving radio network controller (RNC) of the UMTS radio access network (UTRAN), allowing the ciphering of data transferred over the radio link.
There are occasions when authorisation and authentication are required at the application level, rather then just at the network level. In some cases, ciphering of data at the application layer may also be desirable or even necessary. One might consider for example the case where encrypted video data is “broadcast” from a web server to subscribers of the broadcast service. Subscribers must first authenticate themselves to the web server, and are thereafter provided with a key for decrypting the broadcast data. Rather than providing a wholly separate mechanism for facilitating such application layer security, proposals have been made to allow this security to be “bootstrapped” on the 3GPP authentication infrastructure including the AuC, USIM, and 3GPP AKA protocol. This approach anticipates, at least initially, that the application function on the network side is under the control of the access network operator, although this need not be the case if some other trust relationship exists between the access network operator and the operator of the network where the application function is located.
3GPP TS 33.220 describes a generic bootstrapping architecture (GBA) mechanism for bootstrapping authentication and key agreement procedures for application security on the 3GPP AKA mechanism. The new procedure introduces a network based function known as the bootstrapping server function (BSF) which is located in the HE of a user. The BSF communicates with the AuC, that is the home subscriber subsystem (HSS), to obtain, upon request, authentication vectors. The interface between the BSF and the HSS is known as the Zh interface. The functional entity which implements the application function on the network side is referred to as the network application function (NAF). The NAF communicates with the BSF via the Zn interface (using for example the DIAMETER protocol). The interfaces between the user equipment (UE) and the BSF and NAF are referred to as the Ub and Ua interfaces respectively, and utilise the hypertext transfer protocol (HTTP).
Assuming that a UE establishes that the GBA is to be used with a given NAF, and that the necessary keys do not yet exist, the UE must initiate the HTTP Digest AKA mechanism with the BSF over the Ub interface. (As part of this process, the BSF may modify the vectors obtained from the HSS.) As a result, the UE is authenticated by the BSF and is provided with the necessary security keys. In addition, the UE is provided with a transaction identifier (TI). This TI is then provided by the UE to the NAF over the Ua interface. The NAF sends the TI to the BSF and receives in return the associated security keys. The UE and the NAF can then use the Ua interface in a secure way.
Whilst it is not expected that use of the Ub interface will be frequent (n.b. the same keying material can be re-used with several different NAFs, each new NAF requesting keying material from the BSF using the common TI), when it is used it is time consuming. For example, ten round trips are involved assuming that HTTP Digest is used on the Ua interface. Furthermore, the UE must make use of two separate transport layer connections in order to communicate with both the NAF and the BSF, resulting in a high level of transport layer resources.